Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/dhc/dhc-minutes-91jul.txt

Text File | 1993-02-17 | 10KB | 280 lines

CURRENT_MEETING_REPORT_


Reported by Ralph Droms/Bucknell

DHC Minutes

Modifications and Extensions to DHCP

The Working Group agreed to the following changes and additions to DHCP.
The DHCP Internet Draft will be edited to reflect these changes.

Changes to Protocol

The client--server protocol has been changed slightly, so that the
client first broadcasts a message to locate available DHCP servers, and
then selects one of the responding servers from which the client obtains
its configuration parameters.

Protocol Messages

Corresponding to the changes to the protocol summarized in section 1.1,
the DHCP messages have been redefined as shown in table 1.

Client--Server Interaction


  1. Client broadcasts DHCPDISCOVER on local physical subnet.
     DHCP/BOOTP relay agents pass the broadcast on to DHCP servers not
     on the same physical subnet.

  2. Servers respond with DHCPOFFER message with all configuration
     parameters including network address.  Servers need not reserve the
     offered network address, although the protocol will work more
     efficiently if the server avoids allocating the offered network
     address to another client.  The DHCPOFFER message is ``unicast'' to
     the client (using the BOOTP relay agent if necessary).

  3. Client receives DHCPOFFER message from server.  Client may choose
     to wait for multiple responses.  Client chooses one server from
     which to request configuration parameters, based on offered
     configuration parameters in the DHCPOFFER messages.  Client
     broadcasts a DHCPREQUEST message, specifying the desired server and
     desired network address in vendor extension fields.  This
     DHCPREQUEST message is broadcast and relayed through BOOTP relay
     agents.  Any DHCP/BOOTP relay agents must ensure that any messages
     from this client are forwarded to the same set of DHCP servers to
     ensure that the DHCPREQUEST message reaches the selected DHCP
     server.

     The client times out and retransmits the DHCPDISCOVER message if
     the client receives no DHCPOFFER messages.


                                   1





   ___Message_________________________________Use__________________________


   DHCPDISCOVER          Client broadcast to locate available
                         servers.
   DHCPOFFER             Server to client in response to DHCPDISCOVER
                         with offer of configuration parameters.
   DHCPREQUEST           Client broadcast to servers requesting
                         offered parameters from one server and
                         implicitly declining offers from all others.
   DHCPACK               Server to client with configuration
                         parameters, including committed network
                         address.
   DHCPNAK               Server to client declining request for
                         configuration parameters (e.g., requested
                         network address already allocated).
   DHCPDECLINE           Client to server indicating configuration
                         parameters (e.g., network address) invalid.
   DHCPRELEASE           Client to server relinquishing network
                         address and cancelling remaining lease.

   Table 1:  DHCP Messages

4. Servers receive the DHCPREQUEST broadcast from the client.  The
   servers not selected in the DHCPREQUEST message use the message as
   notification that the client has declined that server's offer.  The
   server selected in the DHCPREQUEST commits the binding for the
   client to persistent storage and responds with a DHCPACK message
   containing the configuration parameters for the requesting client.
   The server inserts a unique lease identification cookie as a vendor
   extension.

   If the selected server is unable to satisfy the DHCPREQUEST (e.g.,
   the requested network address has been allocated), the server
   responds with a DHCPNAK.

5. Client receives the DHCPACK with configuration parameters.  The
   client performs a last minute check on the parameters (e.g., ARP
   for allocated network address), and notes the duration of the lease
   and the lease identification cookie specified in the DHCPACK
   message.  At this point, the client is configured.

   If the client detects a problem with the parameters in the DHCPACK
   message, the client sends a DHCPDECLINE message to the server and
   restarts the configuration process.



                                 2






             _________Extension_________Tag________Values________Length_
              DHCP message type          51  1=DHCPDISCOVER         [3]
                                           2=DHCPOFFER
                                           3=DHCPREQUEST
                                           4=DHCPDECLINE
                                           5=DHCPACK
                                           6=DHCPNAK
                                           7=DHCPRELEASE

              Lease identifier cookie    52  address                [6]

              Server identifier          53  address                [6]

              Parameter request vector   54  256 bit (32 octet)    [34]
                                           vector

              Parameter request list     55  n parameter tags     [n+2]



     Table 2:  New Vendor Extensions

     If the client receives a DHCPNAK message, the client restarts the
     configuration process.

     The client times out and retransmits the DHCPREQUEST message if the
     client receives neither a DHCPACK or a DHCPNAK message.

  6. A client may choose to relinquish its lease on a network address by
     sending a DHCPRELEASE to the server.  The client identifies the
     lease to be released with the lease identification cookie.


New Vendor Extensions

The modifications to DHCP require some new vendor extensions, as listed
in table 2.

Use of Vendor Extensions

A client can fill in vendor extensions in a DHCPDISCOVER and DHCPREQUEST
to supply hints or request specific values from a server.  For example,
the client can fill in the 'IP address' vendor extensions to suggest a
remembered network address The server fills in vendor extensions in
DHCPDISCOVER and DHCPACK messages to supply specific configuration
values to the client.

A client can also request specific configuration parameters without
supplying hints through the ``parameter request vector'' and ``parameter
request list'' vendor extensions.  In the parameter request vector, a
one bit in position n in the vector represents an explicit request for
the vendor extensions parameter with tag n.  The parameter request list

                                   3





is a list of vendor extension tags explicitly requested by the client.

Lease Durations and Clock Drift

The algorithm for lease duration interpretation given in subsection 6.1
of the DHCP Internet Draft is correct, assuming the client and server
clocks are stable relative to each other.  If there is drift between the
two clocks, the server may still consider the lease expired before the
client does.  To compensate, the server may return a different lease
duration to the client than the server commits to its local database of
client information.

Lease Renewal Times

The client attempts to renew its lease from the allocating server
beginning at time T1and from any available server at time T2.  Times T1
and T2 are configurable by the server through vendor extensions.
T1defaults to (0.5 * duration_of_lease).  T2 defaults to (0.875 *
duration_of_lease).

XID Field

The XID field must be interpreted by the server relative to individual
clients, not as a globally unique value.

Retransmission

The client drives all retransmissions of the protocol.  The protocol
document still needs explicit descriptions of retransmission and
exponential backoff algorithms.

``ciaddr'' (Clarification)

The ``ciaddr'' field is to be filled in by the client only if the client
has explicit knowledge of its network address.  The client can supply a
hint or a preferred network address through the IP address vendor
extension.

If a server receives a DHCPDISCOVER or DHCPREQUEST message with an
invalid ``ciaddr'', the server silently discards the message.

Use of DHCP in Hosts with Multiple Interfaces

A host with multiple network interfaces must use DHCP through each
interface independently to obtain configuration information parameters
for those separate interfaces.

DHCP and BOOTP Clients

Use of the vendor extensions defined in DHCP is not restricted to DHCP
clients and servers.  Existing BOOTP clients and servers may choose to
use the newly defined vendor extensions.  The one restriction is that
BOOTP clients MAY NOT use the ``DHCP client'' vendor extensions.  Only
clients using DHCP may use the ``DHCP client'' vendor extension.

                                   4





Implementations

Several members of the DHC Working Group indicated that they intend to
work on independent implementations of DHCP. Completion of at least one
of these implementations is expected before the Spring, 1992 IETF
meeting.

Future Work

Greg Minshall agreed to develop a definition of the DHCP server-server
protocol.  Jesse Walker and Walt Wimer agreed to collaborate on the
definition of a MIB for DHCP servers.

Attendees

Steve Alexander          [e-mail]
Richard Basch            [e-mail]
David Bridgham           [e-mail]
Gregory Bruell           [e-mail]
Richard Cogger           [e-mail]
Steve Deering            [e-mail]
Ralph Droms              [e-mail]
Karen Frisa              [e-mail]
Robert Gilligan          [e-mail]
Ron Jacoby               [e-mail]
Douglas Kerr             [e-mail]
Michael Khalandovsky     [e-mail]
Holly Knight             [e-mail]
Nik Langrind             [e-mail]
Joshua Littlefield       [e-mail]
Greg Minshall            [e-mail]
William Nowicki          [e-mail]
Michael O'Dell           [e-mail]
Bradford Parker          [e-mail]
Mark Saake               [e-mail]
Jesse Walker             [e-mail]@decpa.dec.com
Jonathan Wenocur         [e-mail]
Walter Wimer             [e-mail]
John Wobus               [e-mail]



                                   5